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application programming interfaces (APIs). Access to the SpendCap Manager™ module 200 is 
done via a uniform resource locator (URL) with special keyword that the web server 203 
intercepts and redirects to the SpendCap Manager™ module 200 for processing. 



Paragraph on page 8, lines 11-17 



A user 201 may access the SpendCap Manager™ module 200 via a local server or 
independent service provider server 202 that is connected to the Internet 204. Alternately, the 
user 201 may connect directly or indirectly to the Internet 204 with a suitable browser to create 
>^ a department object in step 207. A department object is created in step 207 for the department 
109 in which the user 201 belongs if it has not already been created. A department object 
contains its assigned spending capacity and expenses of the department 109 of the user 201 
organized in multiple plan objects. A plan object represents a category of spending (called 
spend accounts 406) of the department 109, such as headcount, salary, travel expenses, and 
miscellaneous spending. 



Paragraph on page 9, line 29 - page 10, line 5 



Steps 205 and 206 for logging on and authentication is produced when the two hash 
values equal, and thus the user is authenticated thereby in step 512. If the two hash values do 
not equal, the user is not authenticated in step 514. 



Paragraph on page 10, line 23 - page 11, line 6 



TM 



Referring now to Figure 4, the application structure 400 of the SpendCap Manager 
Module is shown. Organization hierarchy 404 is an internal tree structure that closely mirrors 
the organizational structure of the associated company or organization. The organization 
hierarchy 404 is designed to capture the parent-child relationship of department objects. For 
example, the organization hierarchy 404 will implement the reporting structure in an 
organization, so that all departments under a particular manager will be children in the 
hierarchy with the manager's department as their parent. For example, in Figure 4, if the 
manager is in charge of a first department 409, and has a second department 410 and a third 
department 41 1 reporting to the manager, the organizational hierarchy 404 will reflect this 
parent-child relationship as shown in Figure 4. Second department 410 and third department 
41 1 will be children of parent first department 409 in the hierarchy 404. Similarly, fourth 
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department 412, which reports to the manager of department 41 1 , will be arranged in the 
hierarchy 404 as a child of parent third department 41 1, as will be child fifth department 413. 

Paragraph on page 11, lin es 17-20 

The organization hierarchy 404 shown in Figure 4 helps to enforce the access privilege 
of a user 201 . Typically, a user 201 with department access will have access to his or her own 
department 409 for data entry and edit capability, and access to all departments or sub- 
departments 410, 41 1, 412 and 413 below him or her in the hierarchy with viewing ability. 

Paragraph on page 11, lines 21-27 

Each department is associated with a specific subset of the global set of spend accounts 
406. The list of users 402, the organization hierarchy 404, the set of spend accounts 406, and 
the mappings among them are all configurable on an on-going basis to match the changing 
needs of the deploying organization. The configuration as well as all data in the system is 
coupled into the stored centrally in a single database 408 via 403, 405, and 407, respectively. 
Individual users can access this central database 408 easily via the Internet 204 through web 
browsers from their own computers, such as described above for user 201 with reference to 
Figure 2. 



Paragraph on page 11, line 31 - page 12, line 15 

The SpendCap™ Manager simplifies planning by easily accommodating organizational 
needs and changes. The organizational hierarchy 404, users 402, spend accounts 406, business 
drivers, and plan timing elements of a business can be defined and customized by users with 
administrative rights and administrative access via an easy-to-use interface. Changes to this 
information can be done in real time. This capability is especially valuable for companies that 
are growing quickly, and those that undergo frequent merger and acquisition or re-organization 
activities. In addition, this capability provides tremendous flexibility to an organization to 
change or respond to market or other changing conditions. In addition, although the present 
example has been described with reference to the head of Finance 602 having administrative 
rights, it should be understood that a plurality of users may have such rights. For example, the 
CEO 601 may have administrative rights. Also, some users may be provided with 
administrative rights for only a portion of the organization hierarchy 404, which may be 
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referred to as sub-administrative rights. For example, user Steve 603 in charge of R&D may 
have sub-administrative rights for the portion of the organization 609, 605, 606 and 610 that 
reports directly to his department can conduct planning by modifying data contained in the 
corresponding department object 703. The user can also view, but not modify, data contained 
in the department objects, which are subsets of the department object. For example, in Figure 
7, the user Steve 603 associated with department 703 could also view, but not modify, data 
contained in the department objects 709, 705, 706, and 710, which are subsets of the 
department object 703. 

Paragraph on page 13, lines 20-29 

The layout of the department hierarchy 700 is configured during deployment. Therefore 
the relationship between each department object in the department hierarchy 700 is also 
configured at that time. Each department object 703 contains, in addition to the financial data 
in plan objects 713 and configuration data 714, a reference 71 1 to its parent department object 
701 and list of references 712 to its child department objects 709, 705, 706 and 710. The 
department object 703 shown in Figure 7 is depicted in detail, with it being understood that all 
department objects contain similar details which are not shown in the illustrated example. A 
change to this department hierarchy 700, such as in the case of a company re-organization, will 
require the re-configuration of the relationship of the affected department objects. This will be 
one of the tasks for an administrator, such as user Cindy 602. 

Paragraph on page 13, line 30 - page 14, line 7 

When a user, such as a user Steve 603, wishes to assign spending capacity to sub- 
departments 609, 605, 606 and 610, the department objects 709, 705, 706 and 710, 
respectively, for the sub-departments 609, 605, 606 and 610 are retrieved from the department 
hierarchy 700, starting from the user's department object 703 and down the list of references 
712 of sub-department objects 709, 705, 706 and 710 contained in the user's department object 
703. Once it is obtained, the user Steve 603 is shown the list of references 712. Any existing 
spending capacity is displayed; the user Steve 603 can change any of the spending capacity and 
save the changes. The changes are saved in the corresponding department object's spending 
capacity plan object 713, which is eventually persisted to a data store 408 such as a relational 
database system. 
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Paragraph on page 14, lines 8-19 



Planning for a department's own expenses are accomplished in a similar fashion. The 
user Steve 603 selects which spending category he wants to plan. The system retrieves plan 
objects 713 for the selected category from the user's department object 703. The spend account 
data included in configuration data 714 is shown to the user Steve 603. Any existing spending 
is included in the display. The user Steve 603 can make modifications to the planned spending 
\0 and save the changes. The changes are reflected in the plan object 713 and eventually persisted 
to the database 408. This process is repeated for planning each spend account in the 
department object 703. The sum of the total of all the spending accounts and the total allocated 
spending capacity to the sub-departments 609, 605, 606 and 610 must not exceed the spending 
capacity assigned to this department for user Steve 603, as in the spending capacity plan in plan 
objects 7 13 in the department object 703. If the sum is over the spending capacity, the user 
Steve 603 can submit a request for additional funds, as shown in step 212 in Figure 3. 



Paragraph on page 14, lines 20-26 



If the additional funding is granted, the plan can be published as shown in step 210 in 
Figure 3. The step 210 of publishing a plan is accomplished by copying all of the plan objects 
713 in the department object 703 and marking them as public. If a plan has been published 
previously, it will be over-written by the newly published data. The original plan objects 713 
remain in the department object 703, except they are marked as private. The user Steve 603 
refining a plan will only modify the plan objects 713 that are marked with a private designation 
until it is decided to publish the plan. 



Paragraph on page 14, line 27 - page 15, line 1 



A department object 703 is added to the department hierarchy 700 by setting the parent 
department field 71 1 of the department object 703 to an existing department object 701 that 
physically represents the parent department 601 of the department for the user Steve 603. 
Child departments 609 605, 606 and 610 are added by adding department objects 709, 705, 706 
and 710 representing the physical child departments 609, 605, 606 and 610 of the department 
for the user Steve 603 to the list of references 712, which may also be referred to as the child 
department field of the department object 703. 
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Paragraph on page 15, lines 2-14 



A department object 703 may contain configuration data 714 such as plan structures of 
the plan objects, spend accounts, headcount types, salary-related rates, salary adjustment rates, 
available currencies, and business drivers. However, such configuration data 714 is not 
required in every department object. A department object may not physically contain any such 
configuration data. A setting for applicable configuration data 714 will be inherited from the 
parent department object 703 by sub-departments 609, 605, 606 and 610 if the configuration 
data 7 1 4 is not defined in sub-department objects 709, 705, 706 and 7 1 0. If a setting is defined 
in configuration data 714 contained in a particular department object 703, it is specific only to 
the department object 703 and is modifiable by the user Steve 603 associated with the 
department object 703. When a setting is inherited, for example by the department object 705 
from the parent department object 703, the configuration data 714 cannot be modified except 
by the user Steve 603 of the department object 703 from which the setting is inherited. 



Insert the Following Paragraph on page 17 between lines 19 and 29 



For example, in Figure 8, corporate sets the overall spending capacity in step 801. Then 
in step 802, the spending capacity is distributed to various departments from the top down. The 
distribution in step 802 first occurs in the private planning area called "MYPLAN." Then in 
step 803, the spending capacity is published into a public "SHAREDPLAN." In step 804, the 
spending capacity is distributed further down the organization through the same private/public 
mechanism. In step 805, each department performs a bottom-up expense planning, first in a 
private working area "MYPLAN." Then in step 806, the expense plan is published into a 
public "SHAREDPLAN." As depicted in step 807, if a department requires more funding than 
its allocated spending capacity, the department can generate a request to the department's 
parent department for additional funding. 



Insert the Following Paragraph on page 17 between lines 25 and 26 

For example in Figure 9, a user modifies the private copies of his plans in the private 
planning area and commits changes, as depicted in step 901 . Such changes only affect the 
private copies. In step 902, the user attempts to publish his plans. Then in step 903, assuming 
the user's plan is under the spending capacity, the private copies are copied over the public 
copies. m 
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Paragraph on page 17, line 29 - page 18, line 2 



Certain department expenses are driven off business drivers. Headcount 1004 is a 
business driver and is represented by the headcount plan object 1008. The headcount plan 
object 1008 contains the headcount data 1010 having the total headcount of the department, 
including the start/end date, the headcount type which maps to salary or hourly rate. The 
expenses driven off the headcount plan object include the salary and compensation plan and 
other expense plans. 



Paragraph on page 18, lines 12-17 



The major expense plan contain a list of line items (minor accounts) that are associated 
to it such as meal, lodge, car-rental, mileage are to travel expense. Each line item is specified 
as a fixed amount of spending per headcount and/or a percentage of salary per headcount. The 
plan computes the actual expenses of each line item by multiplying the fixed amount with the 
total headcount or multiplying the specified rate, such as the fringe rate 1006 depicted in Figure 
10, with the salary of each headcount. 

Paragraph on pag e 20, lines 6-12 

Referring to Figure 1 1 , when a user submits a request for additional funds as in step 
1 101 , a request object 1 1 1 1 is created. Request object 1111 contains a reference to the source 
department object 1 120, destination department object, the current assigned spending capacity, 
and the additional funds requested. The source department object is the department object 
requesting the additional funds. The destination department object is the department object 
approving the request, usually the parent department object. In step 1 102, request object 1111 
is sent to the messaging system 1 1 12 in the SpendCap application for forwarding to the 
destination department object 1116. 



Paragraph on page 20, lines 13-25 



Messaging system 1 1 12 is a mechanism in the SpendCap server for sending data among 
department objects. When request object 1 1 1 1 is received by the messaging system 1112, 
request object 1 1 1 1 is appended to an internal queue. Requests in the queue are processed in 
the sequence they are added by a separate thread running in the background, such as 
background thread 1113. In step 1 103, background thread 1113 retrieves a request at a time 
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and in step 1 104 forwards the request to the destination department object 1110, which adds the 
request to its own internal queue of requests. The requests will show up when the user of the 
destination department checks for requests in the request page of the SpendCap application. In 
step 1 105, the user can approve, partially approve or reject a request. In any case, in step 1 106 
a response to the request is submitted back to the messaging system 1112. The response is 
encapsulated in a response object 1118. Response object 1118 contains a reference to the 
source department object that is the destination department object 1 1 16 in the request object 
1 1 1 1, a reference to the destination department object that is the source department object 1 120 
in the request object 1111, whether the funds were approved or rejected, and the amount 
approved if approved. 

Paragraph on pa ge 20, lines 26-31 

The response object 1 1 18 is deposited into the messaging system's internal queue in 
step 1 106. The background thread 1113 retrieves the response object 1 1 18 and forwards it to 
the destination department object in step 1 108. The department object matches the response 
object 1118 with the corresponding request object 1 1 1 1 and updates the status of the request. If 
the request was approved, the approved funding is added to the previously assigned spending 
capacity. The new capacity will be used to enforce the spending when the user attempts to 
publish his plan. 

Paragraph on page 21, line 26 - page 22, line 10 

The TopLine Planner™ module 100 is a web-based application that provides the 
functionality of rapidly refreshing revenue forecasts based upon information available to front- 
line participants in a business organization. Revenue forecasts may be updated based upon 
changes in business conditions, such as price changes by competitors, delayed product 
launches, natural disasters, labor strikes, new discoveries, and other factors. This functionality 
improves financial predictability and increases organizational responsiveness. The TopLine 
Planner™ module 100 provides a unified forecasting method, having distributed access within a 
business organization. The TopLine Planner™ module 100 is preferably linked to the 
SpendCap Manager™ module 102, either directly or preferably through the BizPlan™ module 
101. Spend capacity plans may be revised in the SpendCap Manager™ module 102 in response 
to changes in revenue forecasts received from TopLine Planner™ module 100 based upon P&L 
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